gh-153716: Harden ttk/tkinter GUI tests against display scaling#153717
Merged
serhiy-storchaka merged 2 commits intoJul 15, 2026
Merged
Conversation
Compute probe coordinates from the widget's own realized geometry instead of hardcoding pixels such as (5, 5), which land on a different element, or miss it entirely, at a high display scaling. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ixed pixel The arrow-click test helpers probed a fixed x = width - 5, which at a high display scaling on Tk 9.1 lands in the arrow element's right-hand border (the border scales with the DPI), so identify() there returns 'field' and the test fails. Scan inward from the right edge for the arrow element instead. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
serhiy-storchaka
added
needs backport to 3.13
|
Thanks @serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14, 3.15. |
|
GH-153737 is a backport of this pull request to the 3.15 branch. |
|
Sorry, @serhiy-storchaka, I could not cleanly backport this to |
bedevere-app
Bot
removed
the
needs backport to 3.15
|
GH-153738 is a backport of this pull request to the 3.14 branch. |
serhiy-storchaka
added a commit
that referenced
this pull request
Jul 15, 2026
GH-153717) (GH-153738) Compute probe coordinates from each widget's own realized geometry instead of hardcoding pixels such as (5, 5) or width - 5, which land on a different element, or miss it entirely, at a high display scaling. (cherry picked from commit 87411d0) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
serhiy-storchaka
added a commit
that referenced
this pull request
Jul 15, 2026
GH-153717) (GH-153737) Compute probe coordinates from each widget's own realized geometry instead of hardcoding pixels such as (5, 5) or width - 5, which land on a different element, or miss it entirely, at a high display scaling. (cherry picked from commit 87411d0) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
GH-153743 is a backport of this pull request to the 3.13 branch. |
serhiy-storchaka
added a commit
that referenced
this pull request
Jul 15, 2026
GH-153717) (GH-153743) Compute probe coordinates from each widget's own realized geometry instead of hardcoding pixels such as (5, 5) or width - 5, which land on a different element, or miss it entirely, at a high display scaling. (cherry picked from commit 87411d0) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Several
test_ttkandtest_tkinterGUI tests probed widget elements at fixed pixel coordinates (typically(5, 5)) or scanned a fixed pixel range (range(5, 100, 5),range(0, 100, 10)). ttk element geometry — tab padding, the focus ring, trough insets, row height — scales with the display DPI (tk scaling), so a fixed pixel that lands on the intended element at a normal scaling lands on a different element, or misses it entirely, at a high DPI. The test then either fails outright or passes by accident, its assertion accepting''(the "nothing here" result) so it never actually exercises the behaviour it claims to.This surfaces on Retina/HiDPI macOS (Homebrew Tk 9, scaling 2.0) and on any X11 display with a high
-dpi.The probe coordinates are now computed from each widget's own realized geometry instead of being hardcoded:
NotebookTest._tab_point()— a new helper returning a point that really lies on a given tab, via thettk::notebook index @x,ysubcommand. Used bytest_traversal(which now also asserts the selection before and after the click) andtest_tab_identifiers.EntryTest.test_identify— probes the widget centre (winfo_width()/winfo_height()).TreeviewTest.test_tag_bind— scans the realwinfo_height()for item rows.ScaleTest.test_identify— probes the trough centreline fromScale.coords().This makes the tests position-, theme-, platform- and scaling-agnostic and removes the darwin coordinate special-cases.
Test-only change. Verified across scaling 1–6 (DPI 72–432) on Tk 8.6.17 and 9.0.3.
🤖 Generated with Claude Code